Proxy-based communications architecture

ABSTRACT

A method and apparatus turns a typical home telephone system into a platform for delivery of web based content and services. The preferred embodiment of the invention comprises a broadband enabled telephone system for the home and a series of web servers that collect, package, and deliver personalized content and services to all of the telephone handsets throughout the home. With this end-to-end solution, any information or services available via the web can be delivered through a broadband enabled telephone system. Through the web, each member of a family can build a profile which defines what information and services they want available through the handset. In addition, each handset can be dynamically personalized for any family member. The color screens on the handsets become windows through which an individual can view and interact with a broad range of content and services. The audio channels thus become an extension of the voice based services, such as messaging and voice chat.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of co-pending U.S. patentapplication Ser. No. 11/175,991, filed 5 Jul. 2005, which claimspriority to U.S. provisional patent application Ser. No. 60/585,375,filed 2 Jul. 2004, each of which is incorporated herein in its entiretyby this reference thereto.

BACKGROUND OF THE INVENTION

1. Technical Field

The invention relates to a communications architecture. Moreparticularly, the invention relates to services provided in connectionwith a proxy-based communications architecture.

2. Description of the Prior Art

In today's connected world, the telephone stubbornly remains a key modeof communications that is not connected to all the information one needsto simplify their life. How many times is it necessary to look up anumber on a cell telephone or PC just to dial it from a home telephone?How many times is a call placed into voicemail only to find unimportantor previously heard messages? How many times is a time critical e-mailfrom a school, sports team, or other organization missed? How often isit desirable to know whether someone was available before they werecalled? And, how many times are individuals late for an appointmentbecause they didn't look at their calendar or because of trafficproblems? It would be advantageous to use the most familiar andubiquitous communications appliance—the telephone—to tie all of thisinformation together in a manner that is both effortless for the userand seamless with regard to integration into existing infrastructure.

SUMMARY OF THE INVENTION

The presently preferred embodiment of the invention comprises a methodand apparatus that turns an existing communications device, such as thehome telephone system into a platform for delivery of web based contentand services. The preferred embodiment of the invention comprises abroadband enabled telephone system for the home and a series of webservers that collect, package, and deliver personalized content andservices to all of the telephone handsets throughout the home. With thisend-to-end solution, any information or services available via the webcan be delivered through a broadband enabled telephone system. Throughthe web, each member of a family can build a profile which defines whatinformation and services they want available through the handset. Inaddition, each handset can be dynamically personalized for any familymember. The color screens on the handsets become windows through whichan individual can view and interact with a broad range of content andservices. The audio channels thus become an extension of the voice basedservices, such as messaging and voice chat.

Extending Communications Services

With the disclosed inventive method and apparatus, it is no longernecessary for one to be tethered to a PC to look up telephone numbers,do instant messaging, or access voice and e-mail inboxes. Completecommunications services are brought to individuals on any handset in thehouse. With the invention, it is possible to see a personal ornetwork-based phonebook or an up-to-the minute buddy list from a hometelephone. In addition, not only is it possible to read IMs and e-mails,but an individual can also reply to messages using either text or voice.Additionally, every handset in the house becomes a presence-enabledterminal for peer-to-peer voice calls.

Broadcasting Content

One embodiment of the invention allows an individual to identify whatinformation he wants to see and when he wants to see it. For example,the telephone can be set to wake the individual up and deliver thecurrent weather forecast, traffic conditions or daily horoscope right tohis bedside. In another example, the telephone can notify the individualof the winning lottery numbers as soon as the lottery drawing iscomplete. In a further example, the telephone can remind you that theindividual to take the kids to practice in ten minutes. Thus, thisembodiment of the invention provides a web portal for each family memberin which information preferences and triggers can be individuallydesigned. Another embodiment of the invention provides delivery of localdirectory search (LDS) results, along with related ads, coupons, orother promotional items. The invention also comprises servers thatupdate and deliver appropriately formatted information right to theindividual's handset, when it is needed or wanted.

Personalizing the Device

In another embodiment of the invention, a device such as the telephoneis an extension of the individual's personality. Each member of thefamily can customize ring tones and screen wallpaper to reflect theirfavorite sports team, rock band, or even their mood. An individual canpick up any handset in the house, identify who it is, and the telephonedynamically adopts all the elements of the individual's personality.

Controlling the Device

In another embodiment of the invention, the individual can also puthimself in control of such devices as his telephones. The individual canblock calls to his children that come too late or block calls to thefamily that are missing caller ID. The individual can also decide wherein the house calls should ring. Another embodiment of the invention alsoallows the individual to add additional digital telephone lines andnumbers easily and without any additional wiring whether or not a VoIPservice is currently in use.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram showing a proxy-basedcommunications architecture according to the invention;

FIG. 2 is a functional block diagram showing the client architecture ina proxy-based communications architecture according to the invention;

FIG. 3 is a functional block diagram showing a startup sequence forproxy-based communications architecture according to the invention;

FIG. 4 is a functional block diagram showing an authentication withserver sequence for proxy-based communications architecture according tothe invention;

FIG. 5 is a functional block diagram showing an authentication withserver sequence for proxy-based communications architecture according tothe invention;

FIG. 6 is a functional block diagram showing a requesting contentsequence for proxy-based communications architecture according to theinvention;

FIG. 7 is a functional block diagram showing a handling sensitivecontent sequence for proxy-based communications architecture accordingto the invention;

FIG. 8 is a functional block diagram showing a VoIP outcall via browsersequence for proxy-based communications architecture according to theinvention;

FIG. 9 is a functional block diagram showing a VoIP in-call with ringtone sequence for proxy-based communications architecture according tothe invention;

FIG. 10 is a block schematic diagram showing an architecture comprisinga web service instance according to the invention;

FIG. 11 is a block schematic diagram that illustrates how the 2WSarchitecture effectively creates silos for each web applicationaccording to the invention;

FIG. 12 is a block schematic diagram showing a WEB Portal URL Audittrail according to the invention;

FIG. 13 is a block schematic diagram showing a Telephone-System URLAudit Trail according to the invention;

FIG. 14 is a block schematic diagram showing a SIP registration sequenceaccording to the invention;

FIG. 15 is a block schematic diagram showing a voice call sequenceaccording to the invention;

FIG. 16 is a screen shot showing a first step in a telephoneregistration procedure according to the invention;

FIG. 17 is a screen shot showing a step in a telephone registrationprocedure that displays a registration key according to the invention;

FIG. 18 is a screen shot showing a step in a telephone registrationprocedure that displays a password entry dialog according to theinvention;

FIG. 19 is a screen shot showing a step in a telephone registrationprocedure that displays a registration code entry dialog according tothe invention;

FIG. 20 is a screen shot showing a step in a telephone registrationprocedure that indicates successful registration with a serviceaccording to the invention;

FIG. 21 is a screen shot showing a step in a telephone registrationprocedure that indicates successful registration to the client accordingto the invention;

FIG. 22 is a block schematic diagram showing a Proxy Protocol StateMachine (Cold Start) according to the invention;

FIG. 23 is a block schematic diagram showing a Login/Logout ProtocolState Machine according to the invention;

FIG. 24 is a block schematic diagram showing a Power clear ProtocolState Machine (Warm Start) according to the invention;

FIG. 25 is a block schematic diagram showing an EndPointUpdate accordingto the invention;

FIG. 26 is a block schematic diagram showing a runLevel 0:EndPointinitialization according to the invention;

FIG. 27 is a block schematic diagram showing a runLevel 1: EndPointProxyaccording to the invention;

FIG. 28 is a flow diagram showing a new user registration processaccording to the invention;

FIG. 29 is a flow diagram showing network interaction during a new userregistration process according to the invention;

FIG. 30 is a detailed flow diagram showing voicemail integrationaccording to the invention;

FIG. 31 is a flow diagram showing voicemail integration withoutasynchronous notification according to the invention;

FIG. 32 is a flow diagram showing a voicemail delete process accordingto the invention;

FIG. 33 is a flow diagram showing a voicemail listen process accordingto the invention;

FIG. 34 shows SIP application user agent interaction during registrationaccording to the invention;

FIG. 35 shows SIP application user agent interaction for an outgoingMESSAGE according to the invention;

FIG. 36 shows SIP application user agent integration for an incomingMEASSAGE according to the invention; and

FIG. 37 shows SIP application user agent integration for a REGISTER withincoming MESSAGE process according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

A first embodiment of the invention provides a method and apparatus forusing an existing device, such as a home telephone system, as a platformfor delivery of Web-based content and services. A presently preferredembodiment of the invention comprises a broadband-enabled telephonesystem for the home and a series of Web service that collect, package,and deliver personalized content services to all of the telephonehandsets throughout the home. While the discussion herein primarilyaddresses those embodiments of the invention that relate to hometelephones, those skilled in the art will appreciate that the inventionis readily practiced with any existing device that may be connected toan electronic network, such as cellular telephones, Bluetooth and other,e.g. 802.11, such wireless devices including, for example, printers,PDAs, and the like.

Another embodiment of the invention provides a proxy for translatingstandard Session Initiation Protocol (SIP; see, for example, RFC 3261)to multiple peer-to-peer (P2P) networks through network resources. Thisembodiment of the invention allows for access to multiple different P2Pnetworks through a single telephone. This aspect of the inventionprovides a network-based, not client-based, solution. The invention usesstandard SIP call handling for set up and tear down of mediatransmission.

Another embodiment of the invention provides a method for managingmultiple endpoints through a single SIP user address and IP address. Inthis embodiment of the invention, a server is provided that acts as aproxy for multiple endpoints within a telephone system.

A further embodiment of the invention provides a method and apparatusfor leveraging a stimulus/response model for sending network informationthrough home firewalls via SIP, and for receiving responses thereto viaHTML. This embodiment of the invention stimulates a network-based pushusing SIP messages with HTML addresses.

Another embodiment of the invention provides a method and apparatus forinterfacing to an IM network through a network-based IM client andremote interface device. In this embodiment of the invention, the IMclient is on the server. State in the system is maintained independentof the interface device. This embodiment of the invention uses eventnotification for synchronization. This allows multiple endpoints ofpresence independent of the IM network. Thus, multiple users cansimultaneously access the same IM network from a single networkinterface device, such as a home telephone system base station.

Another embodiment of the invention provides a method and apparatus fordelivering and tracking click-to-call information from PSTN and digitaltelephony networks. This embodiment of the invention provides amulti-modal interface for delivering local search information to atelephone handset. This embodiment allows tracking of calls initiatedfrom a telephone handset and the placing of calls through a soft switchso that connectivity can be validated.

Another embodiment of the invention provides a method and apparatus forbinding multiple user profiles and applications to a single telephonedevice through network control. This embodiment of the inventionsupports a variety of users at a single base station and applies avariety of personalities to any single telephone within the system. Thisinvention is related to the IM presence embodiment of the inventiondiscussed above.

A further embodiment of the invention provides for network configurationof calling and personalization of PSTN with network control. Thisembodiment of the invention routes calls to different handsets based onsettings from the Web. Accordingly, the system can play ring tones basedon calling information as configured by the Web. The system also allowsusers to download ring tones via the Web, and block calls by TOD andDOW. User actions on the handset, such as login, binds the handset to aprofile data configured via the Web interface and maintained in anetwork database. Once this binding has occurred, the telephone systemcommunicates with the network database to access user profile and totransfer any user-specific settings and resources. The user profilecontains rules for handling incoming connections from other PSTN or VoIPendpoints. The telephone handset uses caller ID information and currentenvironment, such as TOD, DOW, and user's presence, to determine whetherand how the handset is to be alerted for the incoming connections. Afurther embodiment of the invention provides a method and apparatus fornavigating and accessing a network-based directory through a cordlesstelephone. In this embodiment of the invention a user may navigatethrough WML extensions and load AB as XML data. In this way the user maybring down pieces of the entire AB as needed.

The invention also provides a method and apparatus for bringing togethermultiple content and services from different sources to a single devicevia user selection. This aspect of the invention brings a variety ofcontent to a single telephone device through selections via the Web.

The invention also provides a method and apparatus for storing networkcontent in a bounded, demand-based cache storage in a network endpoint.

The invention further provides a method and apparatus for extendingpresence to communications devices connected to the PSTN network. Inthis embodiment of the invention, a single service keeps tracks ofendpoint activity and reports activity to other devices registered tothe service.

The invention also provides a loosely couple network for delivering andplaying voice attachments from a media server to a VoIP client. Thisembodiment of the invention converts different protocols into the sameVoIP codecs. Thus, this aspect of the invention provides the ability fora device to operate without having to support all encoding standards. Inthe preferred embodiment, standard SIP call handling is used for set upand tear down of media transmission.

The invention also provides a method and apparatus for using the Web toallow users to select a unique VoIP provider and then attach theprovider to a generic VoIP hardware resource. In this embodiment of theinvention, user may select a different VoIP provider from the network.The invention downloads protocol stacks as appropriate and the devicephones home to register with generic network resource.

The invention also provides a system for SIP scalability and automaticsignup. This embodiment of the invention provides dynamic DNS forupdates and wizard entries. For example, a user's Mac address may behashed in one embodiment and provided to the provisioner, which listensfor registration requests. If a valid request is received, a dynamic DNSis assigned.

In contrast to known broadband and digital telephony services such asVonage, Comcast, or P2P, the invention provides the user with access toapplications that compliment telephony architecture. In the preferredembodiment, a thin framework is provided in a telephone device in theform of a small piece of software. The software operates in connectionwith the framework that provides a rendering engine for applications andservices available through the network. This arrangement provides suchelements as a security module that ties the system together usingencryption keys and provides for initial device self registration. Theinvention provides for caching and content that manages information fromthe system, which is provided to the user handset. The information isstored in a content agnostic manner and is pre-cached to a user basestation in anticipation of user accounts. A preferred embodiment of theinvention uses a XML format and templates.

The invention also provides personalization for such things as ringtones, wallpaper, and the like such that the user's home telephoneexperience is similar to that offered in a cell phone environment.

The invention provides call handling functionality similar to that of aPBX system. Thus, all typical functions such as ring tones and avatarsfor caller ID, call blocking and the like, are provided via a managedinterface that is available on the network to the user.

In its broadest sense, the invention is a network offering thatintegrates and interacts with content and services on the network andprovides this content and these services to devices via a proxy suchthat a many-to-many connection is established. A delivery engineaccesses various applications or gateways such as IM, address book,content, and the like and provides these applications to a user portaland a media server, which are accessible from the user's handset via thesoftware module mentioned above. A preferred embodiment of the inventionuses an existing protocol such as SIP for session border control.

Discussion

The presently preferred embodiment of the invention comprises aproxy-based communications architecture which comprises a device-basedthin client element and a server-based suite of applications. FIG. 1 isa functional block diagram showing a proxy-based communicationsarchitecture according to the invention.

The presently preferred embodiment of the invention comprises a methodand apparatus that turns an existing device, such as the home telephonesystem, into a platform for delivery of web based content and services.The preferred embodiment of the invention comprises a broadband enabledtelephone system for the home and a series of web servers that collect,package, and deliver personalized content and services to all of thetelephone handsets throughout the home. With this end-to-end solution,any information or services available via the web can be deliveredthrough a broadband enabled telephone system. Through the web, eachmember of a family can build a profile which defines what informationand services they want available through the handset. In addition, eachhandset can be dynamically personalized for any family member. The colorscreens on the handsets become windows through which an individual canview and interact with a broad range of content and services. The audiochannels thus become an extension of the voice based services, such asmessaging and voice chat.

In FIG. 1, several content-based services 1, including IM, contacts,news, e-mail, photos, calendar, and directory, for example, areavailable to a content delivery service 4, via various related gateways1 a, i.e. a directory gateway, channel manager, IM and P2P gateway, andmessaging gateways for such services as e-mail, voice mail, and SMS. Inthe preferred embodiment, the system is content agnostic. The contentmay be accessed from the source via the content delivery service, or itmay be pre-cached at the content delivery service or at the userlocation in anticipation of user access. Standard techniques, such asXML and the like population of templates may used for content deliveryto the end user.

The content delivery service is also in communication with a user portal9 by which a user may access the overall system, and a personalizationmanager 8, which provides personalization for end user, for exampleproviding a push-to-talk controller. The content delivery serviceprovides content to end user via an P based soft serve switch 3 which ismanaged by a device manager 7 and which provides content and service toend user device 2, via a border control mechanism and a homefirewall/router 6. The firewall/router also provides connectivity forthe end user to VoIP carrier services 5, such as OSS/BSS, a media serverfor such services as voicemail and conferencing, and a VoIP soft switch.Standard telephone services (not shown) are also provided to the userdevice via the home firewall/router.

For purposes of the discussion herein, two elements of the abovedescribed architecture are considered in greater detail, i.e. thecontent delivery service, also referred to as a server, and thecombination of the home firewall/router and end user devices, alsoreferred to collectively as the client. The discussion herein alsoincludes other elements of the architecture, although the interaction ofthese two elements is considered to be of greatest importance inunderstanding the invention.

Some advantages of the invention include:

Extending Communications Services

With the disclosed inventive method and apparatus, it is no longernecessary for one to be tethered to a PC to look up telephone numbers,do instant messaging, or access voice and e-mail inboxes. Completecommunications services are brought to individuals on any handset in thehouse. With the invention, it is possible to see a personal ornetwork-based phonebook or an up-to-the minute buddy list from a hometelephone. In addition, not only is it possible to read IMs and e-mails,but an individual can also reply to messages using either text or voice.Additionally, every handset in the house becomes a presence-enabledterminal for peer-to-peer voice calls.

Broadcasting Content

One embodiment of the invention allows an individual to identify whatinformation he wants to see and when he wants to see it. For example,the telephone can be set to wake the individual up and deliver thecurrent weather forecast, traffic conditions or daily horoscope right tohis bedside. In another example, the telephone can notify the individualof the winning lottery numbers as soon as the lottery drawing iscomplete. In a further example, the telephone can remind you that theindividual to take the kids to practice in ten minutes. Thus, thisembodiment of the invention provides a web portal for each family memberin which information preferences and triggers can be individuallydesigned. Another embodiment of the invention provides delivery of localdirectory search (LDS) results, along with related ads, coupons, orother promotional items. The invention also comprises servers thatupdate and deliver appropriately formatted information right to theindividual's handset, when it is needed or wanted.

Personalizing the Device

In another embodiment of the invention, a device such as the telephoneis an extension of the individual's personality. Each member of thefamily can customize ring tones and screen wallpaper to reflect theirfavorite sports team, rock band, or even their mood. An individual canpick up any handset in the house, identify who it is, and the telephonedynamically adopts all the elements of the individual's personality.

Controlling the Device

In another embodiment of the invention, the individual can also puthimself in control of such devices as his telephones. The individual canblock calls to his children that come too late or block calls to thefamily that are missing caller ID. The individual can also decide wherein the house calls should ring. Another embodiment of the invention alsoallows the individual to add additional digital telephone lines andnumbers easily and without any additional wiring whether or not a VoIPservice is currently in use.

The client in FIG. 1 is shown to include both the home firewall/routerand the user devices. Typically, the user devices comprise handsets,printers, PDAs, and the like, and are communicatively coupled to thehome firewall/router via a wireless transport mechanism, such asBluetooth, 802.11, or the like. The home firewall/router (not limited tohome applications) includes such elements as a security module that userencrypted keys for such activities as initial device registration to thesystem; caching and content facilities for managing information flowfrom the server, i.e. the content delivery service, to the user device;personalization modules for enabling such user selected features as ringtones, wallpaper, and the like; and call handling modules which providefunctionality for the user that is similar to that of a PBX system.

The user devices incorporate a device-based thin client that provides,inter alia, the following:

-   -   Easily-integrated client services    -   Authentication with servers    -   Managed push/pull of browser content    -   Flexible cache of frequently accessed content    -   Integration with telephone system telephony functions, e.g.        caller ID, custom ring tones).        Client Architecture

FIG. 2 is a functional block diagram showing the client architecture aproxy-based communications architecture according to the invention. Theclient comprises, inter alia, an underlying system services layer 10which is comprised of components that include modules for:

-   -   Task creation and synchronization support 12;    -   Providing support for controlling/monitoring handsets 14;    -   Providing SIP, RTP and CODEC support 14;    -   Generating WML content from XML data and templates 15;    -   Providing an interface to system information (not shown); and    -   Flexible heap management for applications 16.

The underlying system adaptation layer 11 is comprised of componentsthat include modules for providing a common API layer between nativeservices and the system, as follows:

-   -   Managing fixed tasks in a flexible thread pool 17;    -   Providing messaging, timer, mutual exclusion support 18;    -   Providing interface to handset controls, events, and browser 19;    -   Providing SIP UA, HTTP Client, DNS, and/or socket APIs 20;    -   System environment and status information 21;    -   Access to network time, locale, and system tick counter 22; and    -   Access to system-level or private heap storage 23.

The underlying system framework layer 24 is comprised of threads 36 thatinclude modules for:

-   -   Supervising all other threads 25;    -   Communicating with the system server (2WS) for content 26;    -   Managing Application SIP UA connections to 2WS 27;    -   Generating WML content from XML data and templates 28;    -   Managing interactions with handset devices 29;    -   Managing an application SIP UA Socket 30; and    -   HTTP Client for content GET and POST actions 31.

Other system components include a library 35 containing modules for:

-   -   Managing cache of system content objects 32;    -   Parsing XML Content and Control Data from 2WS 33; and    -   Providing for encrypted authentication and content 34.

FIG. 3 is a functional block diagram showing a startup sequence forproxy-based communications architecture according to the invention. Inthis phase of system operation, the arrows shown on FIG. 3 indicate thesteps by which:

-   -   Step 1: A supervisor thread starts;    -   Step 2: Component initialization; and    -   Step 3: System threads are started.

FIG. 4 is a functional block diagram showing an authentication withserver sequence for proxy-based communications architecture according tothe invention. In this phase of system operation, the arrows shown onFIG. 4 indicate the steps by which:

-   -   Step 1: Obtain system and user profile;    -   Step 2: Obtain encrypted hash; and    -   Step 3: Authenticate with Server.

FIG. 5 is a functional block diagram showing an authentication withserver sequence for proxy-based communications architecture according tothe invention. In this phase of system operation, the arrows shown onFIG. 5 indicate the steps by which:

-   -   Step 1: Notify 2WS; and    -   Step 2: Respond with first deck.

FIG. 6 is a functional block diagram showing a requesting contentsequence for proxy-based communications architecture according to theinvention. In this phase of system operation, the arrows shown on FIG. 6indicate the steps by which:

-   -   Step 1: Browser issues URI; and    -   Step 2: 2WS Responds via HTTP.

FIG. 7 is a functional block diagram showing a handling sensitivecontent sequence for proxy-based communications architecture accordingto the invention. In this phase of system operation, the arrows shown onFIG. 7 indicate the steps by which:

-   -   Step 1: Encrypted content received;    -   Step 2: Decryption step; and    -   Step 3: Deliver content to browser.

FIG. 8 is a functional block diagram showing a VoIP outcall via browsersequence for proxy-based communications architecture according to theinvention. In this phase of system operation, the arrows shown on FIG. 8indicate the steps by which:

-   -   Step 1: SIP URI Routed to VoIP Services; and    -   Step 2: Call established w/o system.

FIG. 9 is a functional block diagram showing a VoIP in-call with ringtone sequence for proxy-based communications architecture according tothe invention. In this phase of system operation, the arrows shown onFIG. 9 indicate the steps by which:

-   -   Step 1: In call notification sent to system;    -   Step 2: Ring tone located and played; and    -   Step 3: Call answered.        System Framework API

Threading Support API functions 12 (FIG. 2) include:

-   -   QfwCreateThread—Creates a new thread of execution    -   QfwSendThreadMessage—Sends an arbitrary message to a thread    -   QfwWaitForThreadMessage—Receives messages w/timeout    -   QfwSuspendThread—Pauses thread execution    -   QfwResumeThread—Resumes thread execution    -   QfwWaitForMutex—Waits on a mutex object    -   QfwReleaseMutex—Releases a mutex object    -   QfwEnterCriticalSection—Enters a critical section of code    -   QfwLeaveCriticalSection—Leaves a critical section of code    -   Plus additional thread support functions

Telephone System Support API functions 13, 14 (FIG. 2) include:

-   -   QfwGetStatus—Determine status of handsets    -   QfwSendDisplayData—Sends data to handset browser    -   QfwSetDataEventCallback—Creates callback for browser events    -   QfwGetResouceList—Obtain handset resources (ring tones, tones)    -   QfwSetResource—Creates a new resource (ring tone)    -   QfwDeleteResource—Removes a resource (ring tone)    -   QfwPlayResource—Plays a handset resource (ring tone, tone)    -   QfwMakePSTNCall—Initiates a PSTN call    -   QfwMakeVoIPCall—Initiates a VoIP call    -   QfwSetCallProgressCallback—Creates callback for call progress        events    -   QfwSetHandsetEventCallback—Creates callback for handset events        (on/off hook, non-browser key press)

Network Socket and DNS support 15 (FIG. 2) includes:

-   -   Socket support required if SIP interface or HTTP client not        provided in adaptation    -   socket—Creates a socket    -   bind—Binds a socket to local address    -   connect—Connects a socket to a network address    -   send, send to—Sends data via a socket    -   recv, recvfrom—Receives data from a socket    -   gethostbyname—Resolves a host name    -   Socket support must include TCP and UDP sockets. Only blocking        calls are used.

Native Heap Management support 16 (FIG. 2) includes:

-   -   Allows system to use a separate heap space to prevent memory        exhaustion in other subsystems    -   QfwMalloc—Allocates heap    -   QfwFree—Releases heap    -   QfwCalloc—Allocates and clears structures    -   QfwRealloc—Reallocates an existing allocated block    -   QfwStrdup—Duplicates a null-terminated string

System Environment support includes:

-   -   Used to obtain static and dynamic information regarding the        telephone system    -   QfwGetParameter—Obtain (relatively) static information regarding        system        -   Hardware: Model numbers, hardware/firmware revisions, memory            capacity        -   Network: MAC address, local IP address, SIP and 2WS server            information    -   QfwGetStatus—Obtain dynamic status of system components        -   ODSA Status        -   Network Connectivity Status        -   Handset status    -   System Time (SNTP) and Tick Support—Usually supported natively        by ODSA        Web Service High Level Architecture

For the purposes of the following discussion, a telephone system isconfigured as one base and one or more handsets, wi-fi handsets, orother devices. All interactions with the telephone system imply that thebase acts as a proxy for the handsets. Also implied are the SIPentities, e.g. Proxies, Session Border Controllers, etc, that arerequired for SIP messages to be sent to and from a SIP end point. Theterm service provider is used in herein to indicate any vendor thatprovides the needed services. However, for the example herein, theservice provider is a third party provider. Those skilled in the artwill appreciate that the invention can be practiced with any serviceprovider.

FIG. 10 is a block schematic diagram showing an architecture comprisinga web service instance (2WS). The instance shown in FIG. 10 is amulti-layered system that provides heterogeneous services to itsclients. In this sense, a 2WS functions as a portal providing a singleaccess point for many different services, such as Email, Voice Mail,Internet Messaging, Address Book, Local Search, etc. All theinteractions in the following discussion of FIG. 10 and the web servicehigh level architecture shown therein are based on the following:

-   -   2WS web layer 110—this layer handles all incoming requests from        a client, marshals and un-marshals the request, performs access        control and forwards the request to appropriate controllers that        handle it.    -   2WS business/subscriber layer 112—this layer consumes the        published data 11 from the publishers, e.g. content        managers/gateways, email manager/gateways, IM managers/gateways,        etc, and personalizes it for the users.    -   2WS publisher layer 114—this layer interacts with service        providers 113 and retrieves content from them. This content can        be, for example, email, weather, sports, address books, instant        message groups, etc. The content is then published in well known        repositories: It may be in the database 115 or in shared memory,        e.g. using Java Spaces. Once the data is published, interested        parties are notified, either by the publisher or the owner of        the published data, e.g. Java Spaces.    -   DB Layer 116—This is the database persistence layer and it is        where Object Relational Mapping takes place. The ORM engine in        the presently preferred embodiment is Hibernate.    -   JGroups 118—This is a toolkit for multicast communication. In        the inventive service, it is used for inter-process        communication across LAN or WAN boundaries. This mechanism is        not usually bundled with the database Layer. In FIG. 11 its        inclusion in the same space as the database layer only indicates        that it is accessible to all processes.        Multi-Tenancy in the 2WS

The following discussion addresses the inherent capabilities formulti-tenancy designed into the 2WS architecture. With regard tomulti-tenancy, this means that any carrier, telephone vendor, or anyother user can and will have a particular web application serving them.Each particular web application has its own context, including apersistent storage which is separate from every other web application.Multi-tenancy does not impact database clustering or server side loadbalancing. In fact, clustering or load balancing occurs at the web andpersistent layers, and is a over-arching context within which all webapplications run.

FIG. 11 illustrates how the 2WS architecture discussed above effectivelycreates silos for each web application. FIGS. 12 and 13 provide URLaudit trails to indicate how a user request is dispatched to theappropriate application context. FIG. 11 indicates that the tomcatclusters and applications are on one machine. However, the databasecluster is preferably on another machine. This does not impact thenotion of the Silo, however, because each application has a data accesslayer that interacts only with the data source that is bound to it. TheURI provided in FIGS. 11-13 is for clarity only. In a deploymentscenario, the URI would not contain a raw IP address, such as64.81.31.200, but would have a DNS resolvable authority, such as:atx-telephone-service; or atx-web-service; and so on.

Request Processing

The following discussion-describes how URLs from the telephone or from aweb portal are processed. As each element of the URL is consumed, itforms a trail. Following this trail demonstrates how each request isserviced by the appropriate web application. URLs are formattedaccording to RFC 2396′ declaration for an absolute URI. The notion of acommon DB API serving up result sets to various applications does notexist in this model. Each application has a data access object (DAO)which accesses data on behalf of the application. The DAO is bound to asingle database space and no other. Each application has a direct linethrough its DAO to its data source. This methodology promotes the Siloeffect, which reduces the possibility for data cross-pollination to nearzero.

WEB Portal URL Audit trail

-   -   URL: http://64.81.31.200/casabi-atx-service/index.html

First, the request is sent to the wide area network (WAN) which uses thescheme http: and the authority 64.81.31.200 to resolve the IP addressand route the request to the appropriate host (see FIG. 12). Once thehost gets the request, it is passed to the service that is listening forthat request on a particular port. In this case, it is an HTTP request,so the port is 80 and the service is Tomcat. Once Tomcat gets therequest, it processes the path element which contains both theapplication that handles the request and a query string containing anyparameters needed to process the request. Once the web application getsthe request, it processes it appropriately. In this case, the request isto serve up the index or initial web page for the Portal. To do this,the web application must access the database to retrieve the appropriateuser profile, channel data, and other properties used to form a usersprofile. Once the appropriate data values are retrieved, the webapplication formats them and sends them back to the requester, in thiscase an AT&T user accessing the portal.

Telephone-System URL Audit Trail

-   -   URL:        http://64.81.31.200/casabi-rtx-service/imCategory.wmlc?userid=steven&;phoneid=9&;page=1&;        cache=false

First, the request is sent to the wide area network (WAN) which uses thescheme http: and the authority 64.81.31.200 to resolve the IP addressand route the request to the appropriate host. Once the host gets therequest, it is passed to the service that is listening for that requeston a particular port. In this case it is an HTTP request, so the port is80 and the service is Tomcat. Once Tomcat gets the request, it processesthe path element of the URL to forward the request to the appropriateapplication context. Once the web application gets the request, itprocesses it appropriately. In this case, the request is to serve up theIM Buddy list. The web application goes to the database to the userprofile for the current user ID. It then forwards the IM Buddy Listrequest to the publisher for this user. The publisher logs in on behalfof the user, gets the IM Buddy list, and returns it to the webapplication. The web application formats the data for the particulartelephone and sends the IM Buddy list back to the request originator.

Every tenant in the 2WS is associated with a single application contextthat is unique for that tenant. This includes the name of theapplication, its deployed directory, its data source, and any otherresources that it uses. By having a close association between the tenantand an application context, in fact they are virtually the same thing,the walls between tenants become non-permeable and secure. This createsa Silo effect. Each carrier feels that they are the sole users of asystem, which gives them unique resources and branding to create productvalue in the market place.

SIP Proxy for Translating SIP to Multiple P2P Through Network Resources

This embodiment of the invention is a method and apparatus thatcomprises a SIP proxy for translating SIP to multiple peer-to-peerservice providers. A user employs a client device, such as a telephoneon which a SIP client is installed. The SIP client has no knowledge ofthe peer-to-peer service provider, but does have knowledge of thecontent delivery service, i.e. the server. The server comprises a SIPproxy for translating SIP requests from the client device to IMcommunications to multiple peer-to-peer service providers. Thus, theserver translates SIP signaling such that the SIP client on the clientdevice can make SIP calls to IM clients in the service provider'snetwork.

The server keeps a mapping between client devices and peer-to-peerservice providers. When a user identifies himself to the client deviceby logging in, an association of that particular handset to the serviceprovider is invoked at the server. At that point, all messages from thatclient device to the server are associated with that user. If the userwants to initiate a peer-to-peer call to a peer-to-peer serviceprovider, such as Yahoo, for example, the user operates the clientdevice such that the server receives a SIP message that initiates theSIP call. The SIP proxy knows the identity of the user because of themapping and, therefore, can retrieve information about the user. In thiscase, pertinent information, such as the user's IM identity is retrievedfrom a database associated with the server. For example, when a user whohas a Yahoo IM account logs into a client device, the server user knowsthe user's identity. When the user accesses to the IM application, theserver logs him in to the IM application at the service provider andredirects any IM session text between the service provider IMapplication and the client device.

The SIP proxy registers the user with the peer-to-peer servers. Thismakes an association between the service provider's peer-to-peer clientand the SIP proxy. Thus, when a person using a PC want to make apeer-to-peer call to a user, he initiates a peer-to-peer call and themessage goes to the peer-to-peer service SIP server. The SIP serverknows to forward that message on to the SIP proxy because the user isnow registered there.

This translation is executed because the SIP proxy is aware of who theuser is. From the user, the system gets information from the databaseabout the user's IM and peer-to-peer calling identity, as well as theirpasswords and other information. Based on that, the server translatesthe message before it is sent to the peer-to-peer service provider sothat appears to the peer-to-peer service provider as if it is comingfrom one of their clients, and vice versa when a message is sent theother way. Thus, this embodiment of the invention interfaces the IMnetwork from a network IM client to remote interface device.

Key to this embodiment of the invention is the fact that the clientdevice, i.e. the telephone handset, has no knowledge of the IM protocol.The client device is, however, associated with the user. As part of theuser profile, there may be an IM service provider associated with thatuser. If the user has an IM service provider and wants to access the IMservice through the client device, he configures his profile on theserver so that the server knows the identity of his IM service providerand has the credentials necessary so the user can log in tot he serviceprovider's IM application.

The client device has a thin client that has no awareness of the IMprotocol that is used by the user's IM network. In fact, it has noknowledge that it is actually providing an IM service. The serverinteracts with the IM servers on behalf of the IM user associated withthe client device in such a way that it implements the IM protocolbetween the client device and the IM server. The server also sends theproper display messages to the client device, such that it appears tothe user that there is an IM client on the client device. In otherwords, there is a virtual IM client running on the server and therendering device is the client device, so the user can have IMfunctionality in a lightweight platform. The session information ispassed from the client device to the server for the IM session, but theIM session is managed at the server. Thus, the server is really the IMclient and all that is sent to the user are the messages that areexchanged back and forth between the server and the client device.

SIP Registration

FIG. 14 is a block schematic diagram showing a SIP registration sequenceaccording to the invention. In FIG. 14, a SIP Voice User Agent (UA) onsubscriber's home telephone 90 registers with the SIP server 91 (Step1). Web Services 92 act as a proxy for the telephone and logs into thethird party IM server 93 (Step 2; the third party server and otherelements are given by way of example only; those skilled in the art willappreciate that the invention operates readily with any such service).As part of a successful login, the IM server returns authenticationparameters (Step 3). The system uses the authentication parameters toSIP REGISTER with the P2P SIP server 94 (Step 4). Although the telephoneregisters to the SIP server with a generic SIP ID, the SIP serverregisters with IM with the actual IM User ID. This allows multiple usersto logon via multiple handsets and to send and receive IM P2P callsusing the same SIP UA on the telephone.

Voice Call

FIG. 15 is a block schematic diagram showing a voice call sequenceaccording to the invention. The following is simplified view of a P2PSIP call originating from the cordless telephone system to a third partyIM user on another PC. The telephone 90 initiates a P2P SIP call to anonline IM Buddy (Step 1). The call is proxied to the P2P server (Step2). An invite is sent to the IM client 100 (Step 3). The IM clientaccepts the call (Step 4). A response is proxied to the system (Step 5).The telephone receives a response (Step 6). A voice connection isestablished and the call proceeds (Step 7).

Device and End-User Registration

User-2WS Interactions

The following are the high-level scenarios detailing the presentlypreferred, but not the only possible, interaction between a telephonesystem, i.e. base station and hand sets, with the herein disclosedservice instance.

Registration

The goal of the registration process is to bind a user to a system, suchas a telephone system. A telephone system is composed of a base and itshand sets. The role of a base is to act on behalf of the hand sets. Assuch, the base is a proxy for its hand sets. All interaction with thetelephone system preferably occurs solely through the base. It should beappreciated that, while the invention is described herein in connectionwith hand sets, any IP enabled device may be used in practicing theinvention such as, for example but not by way of limitation, printers,PDAs, and the like.

To activate an account, two separate interactions must take place:

-   -   Telephone registration: This consists of making the telephone        known to the service. Once it is complete, the service has        stored the telephone system persistently.    -   Account creation: This process consists of creating an account        in the service, which then binds the account to the telephone        system.

Only when these two interactions are completed successfully, does theservice consider the account active. These interactions are detailed asfollows:

Telephone Registration

With telephone registration, the service becomes aware of a telephonesystem and provides a way for a client to link that telephone system totheir account. In this procedure, a client installs the telephone system117 (FIG. 10), i.e. the base 119 and handsets 121. As soon as thetelephone system comes on line, it contacts the 2WS indicating that atelephone system must be registered. A registration wizard comprising aseries of screens appears on all handsets (see FIG. 16). The clientpresses the registration icon on any one handset. The telephone systemsends a registration message to the service. The registration message isreceived by the service which: authenticates the registration; storesthe telephone system persistently; generates a six digit registrationkey and sets up a time to live for this registration; and returns thisinformation back to the handset. The handset displays the registrationkey to the client (see FIG. 17). It also informs the user that theirservice must be activated by logging into the service provider andcreating an account.

Account Creation

During account creation, the service becomes aware of a client's accountand links the telephone system to the account. A client creates or logsinto his service provider's account. As part of the account creation,the client is redirected to the web service's web pages. At this timethe client must re-login to the web service by entering the serviceprovider's user name and password (see FIG. 18).

The account creation web page requests the following information:Service Provider's name, Service Provider's password, Registration Keywhich was provided by the telephone registration, and PIN, which is anidentifier that uniquely identifies a client (see FIG. 19).

Service profiles comprise the customized services that the client wishesto use, such as Mail, IM, Enhanced Idle Screen, etc. For these services,the client submits the request to the web service. The web serviceperforms the following actions: Authenticate the client user name andpassword with the service provider, e.g. in the case of Yahoo!, logginginto the service provider results in a token which can be used to accessall the clients properties handled by Yahoo!; Create the user's accountwith its associated service profiles; Link the telephone system to theclient through the registration key; and Send a web page back to theuser indicating a successful account registration (see FIG. 20).

The web services then forwards an initial response back to the telephonesystem (see FIG. 21). After the initial response has been sent to theclients, the service activates all of the services for the user, whichconsist of, for example: Email/Voice Mail showing the number of messagesin the in-box; IM which establishes the users presence on the Internet;Address book with a list of addresses; and an Enhanced idle screen withscrolling Headline News.

Hosted Service—Integration Protocol

The invention comprises, in part, a hosted service. FIGS. 28-33 providedetailed flow diagrams that illustrate various processes in connectionwith the hosted service aspect of the invention. A less detaileddiscussion of these processes is provided above.

FIG. 28 is a flow diagram showing a new user registration processaccording to the invention. In FIG. 28, when a service enabled telephonecontacts the hosted service for the first time it provides the user withan initial registration screen The screen points the user to a web-basedwizard that is used to walk the user through a basic systemconfiguration. Once the registration process is complete, the user hasaccess to the carrier branded portal, which allows the user to accessadditional configuration options and other information.

FIG. 29 is a flow diagram showing network interaction during a new userregistration process according to the invention. In FIG. 29, a highlevel view is provided of the network interactions that take placeduring the new user registration process, initial user sign-on, and useraccess of application content. The inventive web service manages thetelephone devices and users by acting as a proxy for the user when theuser wants to access carrier originated application content.

FIG. 30 is a detailed flow diagram showing voicemail integrationaccording to the invention. In FIG. 30, network integrations forvoicemail use are shown. In the example of FIG. 30, it is assumed thatthe voicemail message store supports the IMAP4 protocol, as well as theRFC 2177 extension (IMAP4 IDLE command). RFC2177 allows a mail client toget real-time updates for a selected mailbox, in this case the arrivalof new messages.

FIG. 31 is a flow diagram showing voicemail integration withoutasynchronous notification according to the invention. In FIG. 31, thenetwork interaction for voicemail is simplified if the voicemail systemhas no way to notify a client asynchronously of the arrival of newmessages. That is, if the RFC 2177 protocol, or an equivalent protocolis not supported, then the service cannot dynamically update the messagecount for the user.

FIG. 32 is a flow diagram showing a voicemail delete process accordingto the invention. In FIG. 32, network interaction for voicemail deletionis shown as a straightforward IMAP session with the voicemail system.Once the user selects a voicemail message to view, the user is given theoption to delete it. The delete option causes the service to send theappropriate IMAP command to the voicemail system to delete the message.The service then refetches the mailbox contents and sends the updatedinformation to the telephone for display to the user.

FIG. 33 is a flow diagram showing a voicemail listen process accordingto the invention. In FIG. 33, the network interaction for voicemaillisten includes the calling of the service media server to playback theselected message to the user. When a SIP call is placed to the mediaserver, the service downloads the message body containing the voicemessage, which in this example is assumed to be a WAV file attachment.The file is then transferred to the media server, which then plays themessage back to the connected user.

Protocol State Machine

The following protocol state machine describes the bring-up, i.e. coldstart, of the QFW from a network point of view. The term runlevel isborrowed from OS start-up procedures. Their granularity is intentionallycoarse and they are presented as a basis for discussion only.

Proxy Protocol State Machine (Cold Start)

This state machine (see FIG. 22) indicates the initialization sequenceof the telephone system and how a handset is bound to a user.

runlevel 0:

End Point Update—The QFW sends a SIP Register message to CSIP. The SIPmessage contains the telephone system ID as a hashed MAC address. CSIPforwards the hashed telephone system identifier and the IP address tothe 2WS.

The 2WS checks the telephone system ID and the IP address and ifnecessary updates the persistent storage with the IP address. Itresponds back to CSIP with a 200 OK and CSIP, in turn, forwards this 200OK back to the QFW.

End Point Initialization—The QFW then sends a start-up message to the2WS. This start-up message contains the hashed telephone system ID. The2WS stores this info and then responds with the telephone proxy WMLpage.

runlevel 1:

Telephone Proxy—the user hits the proxy link, the QFW forwards this tothe 2WS. The 2WS registers that telephone system and sends back aregistration page (WML) with a registration code, e.g. six digits. TheQFW takes the registration code, generates a secret, combines this keywith the registration code and presents this as a single registrationkey, e.g. twelve digits, to the user.

runlevel 2:

User Registration/Secret Key Verification—The user uses the ID andsecret key to register through the Web. Once this is complete, the 2WSbinds the user and the telephone system in the DB.

runlevel 3:

Idle/login: Once registration is complete, the 2WS uses a secret keyhandshake with the QFW to validate the secret key. Once the secret keyis validated and, once established, the secret key is used for allmessage validation. The 2WS sends the user a login/idle screen. Thisscreen is continually updated until the user logs in.

runlevel 4:

User login-profile load—The user logs into the 2WS using buttons in theidle screen. The 2WS responds by pushing the user's profile, e.g.services, to the telephone system.

runlevel 5:

Showtime—This is the runtime operation between the telephone system andthe 2WS. This state contains all the runtime operations between the userand the 2WS, including the ability to log out of the system.

Login/Logout Protocol State Machine

The following finite state machine (see FIG. 23) indicates the states ofa telephone system when a user log into and out of a handset. It beginswith a user logging in and then logging out. The states iterate betweenrunlevel 3 and runlevel 5.

runlevel 5:

Showtime—User logs out of the handset. The 2WS receives this and sendsthe user an idle or login screen.

runlevel 3:

Idle/login: The 2WS sends the user a login/idle screen. This screen iscontinually updated until the user logs in.

runlevel 4:

User login-profile load—The user logs into the 2WS using buttons in theidle screen. The 2WS responds by pushing the users profile, e.g.services, to the telephone system.

runlevel 5:

Showtime—This is the runtime operation between the telephone system andthe 2WS. This state contains all the runtime operations between the userand the 2WS, including the ability to log out of the system.

Power clear Protocol State Machine (Warm Start)

This state machine (see FIG. 24) details the events that occur if anactive user power clears the telephone system. The telephone systemcomes up as though it is performing a cold start but, because the useris already known and active, the 2WS considers the QFW to be in theIdle/Login state and all subsequent interactions with the QFW begin fromthere.

runlevel 0:

Cold Start—The QFW sends the MAC address of the telephone system basestation to the 2WS. The 2WS checks this information. It sees that a useris bound to this telephone system. Consequently, user registration isnot required. It goes to runlevel 3 in which the secret key handshake isperformed and the idle screen is sent to the QFW.

runlevel 3:

Idle/login: The 2WS sends the user a login/idle screen. This screen iscontinually updated until the user logs in.

runlevel 4:

User login-profile load—The user logs into the 2WS using buttons in theidle screen. The 2WS responds by pushing the user's profile, e.g.services, to the telephone system.

runlevel 5:

Showtime—This is the runtime operation between the telephone system andthe 2WS. This state contains all the runtime operations between the userand the 2WS, including the ability to log out of the system.

runtime Operations

Email/Unified Messaging

The goal of the email interactions are to provide the client withstandard email features, such as, for example, In-box status; readingand deleting messages; and writing messages, if the handset providesadequate support for this functionality.

Reading Email

From the EIS, a client selects UM. The telephone system requests UMinformation from the service. The service gets the UM information, e.g.email headers, and sends this to the handset. If the number of emailheaders exceeds a predetermined value, the service sends a sub-set ofthe total email headers. To see all the remaining messages, thetelephone system must request more email headers upon user request. Thetelephone system next updates the handset display. The user selects amessage to read. The telephone system sends this request to the service.The service gets the email content, either from the service provider, orfrom stored cache, i.e. Published Data. The service sends the emailcontent, formatted in WML, to the telephone system. The telephone systemdisplays the email content to the user.

Deleting Email

The user has retrieved his email headers from the 2WS web layer. Thislayer handles all incoming requests from a client, marshals andun-marshals the request, performs access control, and forwards therequest to appropriate controllers that handle it. To this point, theservice operates as described above in connection with reading email.The user then selects a message to delete and depresses the delete key.The telephone system sends a delete request to the service. The servicelogins into the service provider and deletes the message. The servicereturns the status back to the telephone system, with a re-ordered listof email headers. The telephone system displays the current page/cardwith a re-ordered list of email headers from which the deleted messagehas been removed.

Voice Mail

Voice mail allows a user to listen to voice mail messages stored intheir voice mail service. In voice mail, the user selects UM from theicons on-screen. The telephone system issues a request to the service.The service returns a list of voice mail entries to the telephonesystem. The user chooses the voice mail entry he wishes to hear andpresses the submit key. The telephone system issues the request to theservice. The service gets the wave file from the service provider. Theservice then loads the wave file onto the media player/gateway. Theservice provides the address of the media gateway to the telephonesystem. The telephone system initiates a SIP session with the MediaGateway. Once the session is established, the media gateway plays thewave file for the user, who hears the voice mail on his handset.

Address Book

The address book feature provides a user with a list of customizedaddresses, e.g. name, telephone numbers, email addresses, etc. Atservice activation (see the Registration discussion above), the servicedownloads the whole address book to the base, together with a WMLtemplate. The service refreshes the address book on the base whenever itchanges in the service provider. When the user depresses the addressbook icon, the base formats the WML pages and serves them up to thehandset. The handset displays the address book content to the user.

Local Search

Local search provides the user with “Yellow Pages” functionality,allowing them to look up resources, such as, for example, movietheaters, malls, restaurants, etc. In the local search function, theuser selects the Local Search icon. The base sends the request to theservice. The service responds with a WML page listing the searchcategories. The user selects an entry from the search categories andclicks on the submit button. The telephone system then sends a requestto the server indicating the selected item. The service goes to theservice provider, which performs the search and returns the results. Theservice stores the results and sends them back to the telephone system.The handset then displays the results.

One embodiment of the invention provides a pay per call feature formerchants who are located by a user of a Local Directory Search. In thisembodiment of the invention, an overlay is provided for the user search,in which various results are listed in preferential order based uponpayment of a placement fee by a merchant, such as a local plumber. Theuser calls one of the listed merchants and the system uses CSIP to trackthe user call to completion. The merchant pays the service for each callit receives via the local directory search. To facilitate contacting thesubscribing merchant, the search results are returned to the user with alink displayed that, upon selection, connects the user directly to themerchant to establish a voice call with the merchant.

Instant Messaging

The instant messaging function provides the user with a list of buddiesthat are on line. To start, the user selects the IM icon on the handset.The telephone system submits the request for the IM service from theservice. The service returns the buddy list to the telephone service. Inthe preferred embodiment, the Buddy List contains E.164 information anda SIP end point. The user selects a buddy. The Handset places a call tothat buddy.

Message Format

The following discussion provides is a generalized notion of a message.These messages can be used between the QFW and 2WS. Only the essentialelements are included and extensions can be added as needed. In thepresently preferred embodiment of the invention, the message schema isexpressed in XML.

A generalized message can be expressed as follows: <message>   <header/>  <content/> </message>Header

A header always has an operation and modifiers for the operation.Modifiers are any attributes defined, or required by, the operations.For instance, if the operation is to download WML, the operation is“DownloadTextFile and the modifiers are fileName and fileType. Anexample of this is: <header>  <op>DownloadTextFile</op>  <fileName>/Mom/AddressBook/Home</fileName>    <fileType>wml</fileType></header>

A header also contains elements, such as hash, which is constructed froma secret key; and name, which may or may not be needed in the finalizedversion. However, these fields are not being used for CES and, for thesake of clarity, are not included. The header can contain otherelements, such as length, etc, if necessary.

Content

Content is the object of the operation. It is the thing operated on,used by the operation, or needed by the operation. In fact, it can beany thing defined or required by, the operation. For example the contentcan be a wml file, xml templates, data, or even a formatted string. Inthis example, it contains wml wrapped in a CDATA construct. For example:<content>   <![CDATA [ <wml>. . . . . . . . . . . . . . . . . . . . ..</wml> ]] > </content>

Putting it all together we have a message constructed as follows:<message>  <header>   <op>DownloadTextFile</op>   <fileName>/Mom/AddressBook/Home</fileName>    <fileType>wml</fileType>  </header>  <content>   <![CDATA [ <wml>. .. . . . . . . . . . . . . . . . . . . .</wml> ]] >  </content></message>

In this model, the message only specifies that it must have a header anda body or content. What is in the header and content depends on theoperation taking place. For instance, to send templates we could do thefollowing: <message>  <header>    <op>DownloadAddressBookTemplates</op>   <fileName>/Mom/AddressBook/Page1</fileName>   <fileType>xml</fileType>  </header>  <content>   <![CDATA [<xml>template. . . .</xml> ]] >  </content> </message>

or to download user data: <message>  <header>  <op>DownloadAddressBookData</op>    <userName>Bill Joy</userName>   <displayName>JavaGuru</displayName>  </header>  <content>    <![CDATA[     <xml>      <contact>        <name>Scott McNeally</name>         <telephone>    <type>work</type>           <number>1-800-call-sun</number>       </contact>     </xml>   ]] >  </content> </message>QFW-2WS InteractionsEndPointUpdate

This message (see FIG. 25) is sent by the SIP Server when it receives aSIP register message for a telephone system and the IP address of thattelephone system has changed. The following are the details/format ofthe EndPointUpdate message. The ID tag is the telephone System ID. TheAOR (address of record) is the SIP address of the info push user agentof the telephone system.

EndPointUpdate, <message>     <header>       <op>EndPointUpdate</op>    </header>     <content>       <phoneSystem>          <ID>CadCExuNJrKu</ID> <aor>sip:userId@IpAddress:Port</aor>      </phoneSystem>     </content>   </message>runLevel 0: EndpointInitialization

The following interaction between the QFW and 2WS (see FIG. 26) occursat runLevel 0. The note in FIG. 26 provides details of the messagestructure used in the interaction. The following are the details of theEndPointinitializationRequest and EndPointinitializationResponsemessages.

End PointInitializationResponse <message>   <header>    <op>EndPointInitializationRequest</op>    <endPointId>HashedMacAddress</endPointId>   <header/> </message>

End PointInitializationResponse <message>   <header>  <op>EndPointProxy</op> <fileName>/<userName>/EndPointProxy</fileName>        <fileType>wml</fileType>     <handSetStrId>All</handSetStrId><pushOption>       <enabled>true</enabled>     </pushOption>    </header>     <content>       <![CDATA [ <wml>. . . . . . . . . . .. . . . . . . . . . .</wml> ]] >     </content>   </message>runLevel 1: EndPointProxy

The following interaction between the QFW and 2WS (see FIG. 27) occursat runLevel 1. The note in FIG. 27 provides details of the messagestructure used in the interaction. The following are the details of theEndPointProxyRequest and EndPointProxyResponse messages.

EndPointProxyRequest <message>  <header>   <op>EndPointProxy</op>  <endPointId>HashedMacAddress</endPointId>  </header>  <content>   <phoneSystem>    <base>     <manufacturerName>IDT</manufacturerName>    <modelNo>1</modelNo>    </base>    <handSet>    <handSetStrId>HS1</handSetStrId>   </handSet>   <handSet>    <handSetStrId>HS2</handSetStrId>   </handSet>   <handSet>    <handSetStrId>HS3</handSetStrId>   </handSet>    </phoneSystem> </content> </message>

EndPointProxyResponse <message>  <header>  <op>EndPointProxyResponse</op>  <fileName>/<userName>/UserRegistration“</fileName>        <fileType>wml</fileType>       <handSetStrId>All</handSetStrId>   <pushOption>      <enabled>true</enabled>       </pushOption>    </header>     <content>        <![CDATA [<wml>......................</wml> ]] >     </content>     </message>2WS-QFW

UserAccountActivation <message>  <header  <op>UserAccountActivation</op>  <fileName>/UserAccountActivation</fileName>     <fileType>wml</fileType>   <handSetStrId>All</handSetStrId>   <pushOption>       <enabled>true</enabled>    </pushOption> </header>  <content>     <authority>www.somename.com</authority>    <![CDATA [ <wml>......................</wml> ]] >  </content></message>

Within the wml in this message there is an href containing a URI. ThisURI is formatted as follows: sip:/casabi-idt-service/signIn?userId=someUser&password=somePwd

When the user hits the submit button this uri is sent in the followingmessage:

QFW-2WS

DataRequest    <message>     <header>  <op>DataRequest</op> <endPointId>hashedMacAddress</endPointId> <handSetStrId>HS1</handSetStrId> </header>  <content><uri>sip:/casabi-idt-service/signIn?userId=someUser&password=somePwd</uri>   </content>   </message>2WS-QFW

The 2WS receives the message and responds with the following message:

Data Response <message>  <header>    <op>DataResponse</op>   <fileName>/userId/signIn.wml</fileName>    <fileType>wml</fileType>   <handSetStrId>HS1</handSetStrId    <pushOption>     <enabled>true</enabled>       </pushOption>    </header>    <content>        <![CDATA [ <wml>......................</wml> ]] >    </content>   </message>QFW-2WS HTTP Interactions

Within the wml in the above message, there are URIs for the variousservices, channels, etc. These URIs are formatted according to RFC 2396sdeclaration for an absolute URI. In effect the URI format works out to:<scheme>:<path><query>

When the user clicks on any of the links in the WML pages, the telephonesends the URI to the QFW which uses the scheme, e.g. SIP, HTTP, etc, todetermine what action needs to be taken and what protocol needs to beused. In this case, the action is to request a resource from the 2WS andthe scheme/protocol is HTTP. The QFW then builds the URL from the URIand sends this URL to the 2WS. The 2WS uses the URL to access/get theappropriate resource and sends it back to the QFW. This interaction isrepeated for all Services that use HTTP.

The methodology for constructing a URL from the URI is to insert theauthority, e.g. www.some-casabi-service.com, between the scheme and thepath. This action converts an absolute URI with a file path into anabsolute URI with a network path. This can be stated as follows: FilePath - <scheme>:<path><query> Network Path -<scheme>:<authority><path><query>

The following examples detail the URI to URL conversion:  AddressBookURI - http:/casabi-idt-service/addrBook?userId=someUserURL   -   http://www.some-casabi-service.com/casabi-idt-service/addrBook?userId=someUser  Channels - Weather URI -http:/casabi-idt-service/weatherChannel?userId=someUserURL   -   http://www.some-casabi-service.com/casabi-idtservice/weatherChannel?userId=someUser  Channels - News URI -http:/casabi-idt-service/newsChannel?userId=someUserURL   -   http://www.some-casabi-service.com/casabi-idtservice/newsChannel?userId=someUser  Channels - Horoscope URI -http:/casabi-idt-service/horoscope?userId=someUserURL   -   http://www.some-casabi-service.com/casabi-idtservice/horoscope?userId=someUser  Email URI -http:/casabi-idt-service/email?userId=someUserURL   -   http://www.some-casabi-service.com/casabi-idt-service/email?userId=someUserSIP Agent Application Interaction

FIGS. 34-37 are flow diagrams showing SIP agent application interactionduring various processes within the service.

FIG. 34 shows SIP application user agent interaction duringregistration. The service does not issue any SIP commands(QfwSipRegister, QfwSipSendMessage) while waiting for acknowledgement(callback) of the previous command. The service does not attempt to senda SIP MESSAGE (QfwSipSendMessage) unless it has received positiveacknowledgement of a SIP REGISTER.

FIG. 35 shows SIP application user agent interaction for an outgoingMESSAGE. The service does not issue any SIP commands (QfwSipRegister,QfwSipSendMessage) while waiting for acknowledgement (callback) of theprevious command. The service does not attempt to send a SIP MESSAGE(QfwSipSendMessage) unless it has received positive acknowledgement of aSIP REGISTER.

FIG. 36 shows SIP application user agent integration for an incomingMESSAGE. The service does not issue any SIP commands (QfwSipRegister,QfwSipSendMessage) while waiting for acknowledgement (callback) of theprevious command. The service does not attempt to send a SIP MESSAGE(QfwSipSendMessage) unless it has received positive acknowledgement of aSIP REGISTER.

FIG. 37 shows SIP application user agent integration for a REGISTER withincoming MESSAGE process. This use case scenario demonstrates theprocess when an incoming MESSAGE is received while the service iswaiting for acknowledgement of a renewal REGISTER request. The serviceaccepts the incoming MESSAGE and processes it normally. The serviceaccepts the incoming acknowledgement of the REGISTER and processes itnormally.

Using the Web to Select a VoIP Provider and Attaching the Provider to aGeneric VoIP Resource.

Currently, when an individual goes into a store and buys a piece ofhardware for a VoIP service, such as Vonage, that hardware is dedicatedto the particular service. When the user connects that hardware, itsinitialization process connects it uniquely to the particular service,e.g. Vonage. A disadvantage for hardware manufacturers, as well as forretailers, is that if the next VoIP provider, e.g. Sun Rockets orCallVantage, wants to get store shelf presence, the retailer must stocka unique piece of hardware for that vendor as well. The hardware isexactly the same, except for where it initially boots up andcommunicates. There might be some protocol differences in the VoIPservice.

To address this issue, the invention provides a service that is thefirst point of contact for such hardware devices. The inventioncomprises a backend service that has a portal associated with it that auser can go to and select which VoIP provider they want to use. Thus,they can select from a list of VoIP providers and then manage theinteraction with the hardware device, download any protocol that may berequired, make whatever configuration changes are required and then thehardware device is uniquely tied to the VoIP service selected by theuser.

An advantage of this aspect of the invention is that it is not necessaryto have unique hardware device for any of the several VoIP serviceproviders. The device manufacturers need only build one version thatcommunicates with the inventive system and the system then manages theinteraction of the hardware device with the VoIP service provider. Theinvention essentially disaggregates the hardware device from the VoIPservice and allows the user, the device manufacturer, and the retailerto have more flexibility.

With the invention, the user need not buy any other hardware. The usermay have their PSTN service with a service provider, such as AT&T andhave their long distance service or second line from another serviceprovider. The user may buy a second PSTN line service from anotherservice provider, or they may buy such service from a VoIP serviceprovider. In all cases, the user does not need to get another piece ofhardware. Thus the invention, unlike dedicated VoIP hardware devices canmanage all services from all service providers through a singleinterface, and the user need not worry about buying a specific piece ofhardware that's tied to a particular service. Henceforth, if a userwants to buy another service, it is not necessary for the user to buyanother piece of hardware. Rather, the user can change service providersby changing their profile through the interface provided by theinvention, and then download their current profiles for the new service,or the user4 could have more than one service by maintaining multipleprofiles. For example, if a user had other people living in their homewith them who wanted to have their own accounts, e.g. a child, spouse,and/or a roommate, then the invention would allow that residence to havemultiple vendors in the same system. This is due to the fact that theinvention allows a user to have a different profile for each hardwaredevice, e.g. handset, and/or for each user of each handset. Because theinvention provides the backend service that enables multiple hardwaredevices and multiple users, each such hardware device and each suchprofile is a network based resource that has attributes which can bechanged without having to change the hardware device itself.

As discussed elsewhere herein, the invention also comprises a browserelement and website that can be accessed from a conventional PC. Some ofthe features discussed are more complicated in nature to set up. In suchcases, it is more appropriate to go through a PC interface rather thanthe limited interface provided, for example, by a handset. Thus, oneaspect of this feature of the invention is the provision of a portalthat is used when configuring such services as VoIP.

Leveraging a Stimulus/Response Model to Send Information Through aFirewall Via SIP and Receiving a Response Via HTML

An overview of the traditional use of SIP and http is first providedhttp is a ubiquitous protocol used by Web browsers in a typical networktopology by a generic Internet user. Such topology comprises thefollowing: a browser which runs on a computing device, where thecomputing device is assigned a network address, for example by a router.The network address is a term used to describe a private IP address,i.e. an address assigned by the router and that is valid only within thedomain of the router, within the network controlled by the router, e.g.within the user's home. The IP address is only valid within the localLAN supported by the router, while other devices on the Internet may ormay not have a global IP address that is valid across the whole of theInternet. Thus, the local address used by a user device according to theinvention has no meaning in the global address base. Accordingly, acomputing device in the global Internet cannot send a message directlyto the local IP address of the user device because the computing deviceand the user device reside in different address bases.

As stated above, the local IP address of the user device has no meaningin the global IP address space. This is not a problem for the httpprotocol which is used for Internet browsing because a browser runningon a user device, e.g. in the home, initiates a session with a serverrunning in the global IP address space, e.g. wwww.yahoo.com, whichtranslates to a global IP address somewhere in the Internet. The routerthat controls the local IP address space allows the browser to initiatea session. In other words, the session is initiated from inside thelocal IP address space. Typically, a firewall runs in the router thatallows a computing device on the user side of the router to initiate anhttp session. The firewall does not allow computing devices outside ofthe private IP address space, for example Yahoo, to initiate a sessionwith the local computer. Thus, a remote server cannot push content pasta firewall to a PC.

The Session Initiation Protocol (SIP) is an application-layer control(signaling) protocol for creating, modifying, and terminating sessionswith one or more participants. These sessions include Internet telephonecalls, multimedia distribution, and multimedia conferences (see RFC3261). SIP clients use TCP or UDP to connect to SIP servers and otherSIP endpoints. SIP is primarily used in setting up and tearing downvoice or video calls. Thus, SIP messages must be able to be pushed intothe local IP address space from the outside. Otherwise, it would not bepossible for someone to call into a VoIP device. Thus, SIP networkingsolves problem of initiating a session from a global IP address space toa local IP address. For purposes of the discussion herein, this isreferred to as a stimulus response model. This embodiment of theinvention leverages the ability of SIP to push content to user devicesthat operate in connection with the inventive server discussed herein.To this end, the invention provides a mechanism that pushes an event andan address to a user device via SIP. The event announces that there iscontent for the user and the address identifies where the user goes toget the content. The address is an http address, typically in the formof a URL. When the SIP message is received at a user device that isenabled by the invention, the user device uses http to pull the contentfrom the address contained in the SIP message.

In the invention, the URL is not something that the user sees. It isinterpreted automatically by the inventive server. For example, considerthe case where traffic alerts are to be pushed to a user's telephone,i.e. a user device connected to the inventive server. Rather than try topush a large packet to the user device that contains the traffic alertitself in a markup language that can be displayed on the user device,because SIP is not meant to transfer large packets, it is not necessaryto set up a session with SIP, but instead a simple SIP message isexchanged to tell the user device that there is content that needs to bedisplayed. The server to which the user device is registered receives anhttp address, e.g. a URL, and then, unbeknownst to the user, without anyuser intervention, the inventive server pulls the content using http. Inthis example, the inventive server receives the SIP message, but interms of the server, externally, there is a SIP call coming in that isto be used to push content such as a traffic alert or a weather alert.What the server sees is an indication or a control signal that says aURL is being sent and the server should go out and follow it. The serverthen follows the URL, gets the information associated with the URL, andthen renders and presents the information to the user on the userdevice. Specifically, in this example software running on a systemcomprising the inventive server and a user device receives a SIP contentretrieval message. The address is in the message is used to retrieve thecontent, which is then rendered and displayed on the user device.

Managing Multiple Endpoints Through a Single SIP User Agent (UA) and IPAddress

SIP is a peer-to-peer protocol, in which SIP endpoints originate andterminate SIP messages. A SIP user agent is an application that runs ontop of the SIP messaging protocol. An endpoint generally refers to a SIPaddress, which comprises a logical part, which is referred to as theuser part, and a host, which is, for example, an IP address or a domainname, which would result in an IP address. An example of a SIP useragent is the software required to effect SIP voice calling. Generally,the user part of the SIP address specifies to the SIP endpoint whichuser agent is handling the address. Thus, in SIP there is a one-to-onemapping between SIP endpoint addresses and the SIP user agent.

In this embodiment of the invention, a single user agent handlesmultiple SIP addresses, rather than one user agent associated with agiven endpoint. For purposes of the discussion herein, the terms“endpoint” and “address” are used interchangeably. In the known art,there is one user application per SIP address. Thus, for a telephonethat is enabled for SIP based voice calling, there is a user agent andendpoints associated with the voice functionality. Similarly, if thetelephone performed other SIP-based function, another endpoint in SIPuser agent would handle that function.

In this embodiment of the invention, there is a single user agent thathandles SIP messages for multiple endpoints. That is useful becausethere is a certain expense associated with supporting endpoints, notonly on the device itself in terms of addresses, but in the SIP networkitself, especially with respect to the part of the SIP infrastructurethat allows penetrating firewalls, there are resources associated withevery endpoint. By managing multiple endpoints through a single UA, theinvention reduces the need for such resources.

Binding Multiple Profiles and Applications to a Single Device throughNetwork Control

This embodiment of the invention comprises a telephone system as per theinvention described herein, which consists of a telephone base stationrunning system software in accordance with the invention describedherein and multiple handsets which have simple rendering devices, suchas a screen for browser-like rendering. In the network, there is anetwork based control for these devices. The network comprises usersand, associated with the user, a profile which indicates features,functionality, and content to which a user has subscribed. Uniquely, inthis embodiment the user device can take on multiple personalities. Infact, if the system is considered the user device, then the device cantake on multiple personalities simultaneously. For example, if thesystem comprises more than one handset, each handset can be associatedto a different user, such that each handset can be behave differentlysimultaneously. This is enabled by the data model in the network whichlists the users and their profiles and the fact that the invention bindsthe handsets to particular users at log-in time.

The binding is part of the registration process which is discussedelsewhere in this document. There is registration of a telephone systemand there is registration of the handsets. Telephone registrationinvolves profile creation, and takes advantage of the fact the inventionallows one to create profiles at the time of telephone registration. Thesystem knows that for each handset there can be a different registrationand a different profile, e.g. a different user source or endpoint. Whenthe user registers a telephone handset for the first time, it isnecessary to create one user, but the invention allows registration ofsubsequent users subsequently.

Delivering and Tracking Click/Call Information for PSTN and DigitalTelephone Networks

This embodiment of the invention concerns sending the results of aclick-to-call or pay-per-call type search to a user of a handsetaccording to the invention herein disclosed, where a search is performedagainst a local directory feed, e.g. local directory searches or genericYellow Pages, for example as provided by Yahoo. At the same time thatthe search is performed, the system accesses multiple pay-per-callvendors who have specific advertisements in specific categories. Thesystem performs a category search for the generic search requested bythe user against a local directory, such as the Yellow Pages. Thecategory is sent to the list of pay-per-call vendors and a matching listof vendors is returned to the user with the search results.

Thus, this embodiment of the invention comprises a combination of YellowPage ads and unique pay-per-call entries. The system combines these ontoa screen such that a user can search on those screens. Uniquely, thisembodiment of the invention combines these search results from disparatesources onto a single screen that a user can then use to browse betweenthe local directory and a pay-per-call listing. When the user clicks ona listing, a call is made directly to the listed service over the PSTNline. Today, pay-per-call is performed on a PC, where a user clicks on alink displayed a PC and the network makes a call in the network. In thiscase, the user must dial a telephone number uniquely from the screen ofthe PC onto his phone. In contrast, this embodiment of the inventionallows the user to select a listing directly on a handset and a call ismade automatically over the PSTN line. Thus, the user device, incombination with the inventive server, provides the interface by whichthe user performs the search, receives the results, selects a listingfrom the results, and is connected to the listed service for voicecommunications. Because the invention combines the pay-per-call adaccessed, for example, from the Web, directly with a user device that isconnected to a PSTN network, the step of dialing the pay-per-call numberis eliminated.

For example, in a session a user might want to find information about aflorist. The user enters information on his handheld device aboutsearching for a florist. Through the inventive server, the user enteredinformation is translated into a search, for example, on the Internet orother servers. A search result on florists is returned to the user thathas two types of information: It has both the advertising informationand also the pay-per-call information. This information is presented tothe user by the inventive server onto the user's handheld device as alist, for example, that might be ordered based on how much advertiserswere paying to be on the list. When the user selects an item from thelist, the inventive server makes a call on the PSTN for the user. Thus,the server recognizes the search results and the telephone numberscontained within such search results, and renders those telephonenumbers onto the screen of the user device, such that when the useraccesses the information, the system then know to make a PSTN call tothe user selected service. IN some embodiments, the system may place acall either over the PSTN line or it can also place the call over a VoIPnetwork and connect directly to the advertiser, as well, bypassing thePSTN network. With this embodiment, it is possible to track whether thecall is connected uniquely to then report to an advertiser that a callwas connected for an amount of time. Thus, this embodiment allows thesystem to track the metrics of the call, e.g. for product revenue or adrevenue purposes. Click throughs are also collected in this way.

Address Book Stored on Service

A presently preferred embodiment of the invention comprises a networkbased address book that appears on the user devices as if this addressbook exists on the user device but, in fact, it is located on thenetwork. One benefit of this embodiment is that address book size is notlimited by the memory available on the user device. In this way, a usercan store a much larger address book, and can synchronize it with othernetwork-based address books and other devices, such as cell phones.

In one embodiment, the address book is stored on a service, in effectvirtualizing a network based address book out onto a user device, e.g. ahandset. The invention keeps the network based address book synchronizedwith the handset, but preferably does not move the entire address bookto the handset.

One embodiment moves the address book into the inventive server, e.g.the handset base station, where it is rendered and presented to thehandset. The handset base station also has a limited amount of memory.If the address book is small, the entire address book is moved to thehandset base station. If the address book is large, then portions of theaddress book are moved to the handset base station in response to usernavigation within the handset. Thus, in one embodiment, the system movesa list to the handset and/or handset base station depending on the typesof keys a user selects on the handset. This aspect of the inventionmimics what a user would expect to do when accessing addresses in a cellphone, e.g. select a key on the keypad and view listings associated withthe selected character. If the user's address book is large, only theset of addresses associated with the user selected key are moved to thehandset, and the user can further navigate within that set of addresses.Thus, this embodiment of the invention permits user access to avirtually unlimited size of address book on a handset, where theaddresses are stored in the network but rendered on the handset.

The invention also allows the user to have multiple address books on thehandset base station for different users at any one time. When a userlogs onto a handset, the system downloads the appropriate address bookfor that user. In other embodiments, it is not necessary to keep alladdress books on the handset base station, which would otherwise limitthe amount of memory available for other system features, but theaddress books can be located on the network and are fetched by thehandset base station in whole or in part as needed.

This embodiment of the invention also provides the ability to have bothshared and personal address books. A shared address book is one thatanybody within a particular group, e.g. a family, can access. In thiscase, when a user makes an address book change, such change is stored inthe address book and the address book repopulated in such a way thatwhoever is logged into their own personal account and has their ownpersonal address book, for example, also has access to the sharedaddress book and is able to see all changes made to the shared addressbook, as well as make changes to the shared address book themselves. Theshared address books are commonly visible to everybody within a group,while personal address books are only for a user's personal access. Incontrast to state of the art network based address books, whichessentially keep a local contact list on a user device synchronized withthe user's network based contacts, the invention maintains the networkbased address book as the user's true list of stored contacts, and onlymoves that portion of the list of contacts contained in the address bookthat is presently required from the network based address book to theuser's local device, e.g. the handset. In this way, the size of theuser's address book, as well as the number of address books that theuser can access, is not limited by the amount of memory on the userdevice.

As discussed above, one embodiment of the invention provides multipleaddress books, some of which may be personal to a particular user. Thus,when a user scrolls through a list of names, the user sees names thatother users do not see when they scroll through a list of names, andvice versa. Thus, the invention integrates all of the multiple addressbooks into a single address book for each user, but the address book isa personal subset of the entire universe of addresses. Accordingly, eachuser can have addresses in common with other users and can haveaddresses that are specific only to them.

As also discussed above, user gestures are used to determine the portionof the address book that the user wants to access. The system rendersonly that portion of the address book that the user appears to need. Inthis way, the user only receives the portion of the address book that heis currently navigating. Thus, the invention provides a means forinterpreting navigation to provide a limited portion of the address bookconsistent with the navigation. For example, if the user is scrollingvery quickly through the alphabet, the system would render portion ofthe address book that corresponds to the letters of the alphabet, e.g.A, B, C and so forth, on the user device when the user stops scrolling.Until the user stops scrolling, the system skips the list of contactsassociated with each letter of the alphabet. As the user slows down thespeed at which he is scrolling, for example, scrolling through D, thesystem starts rendering more information to the user device. Thus, thereare any number of heuristics involved in interpreting user gestures. Forexample, if the user device includes a scroll wheel, the heuristics caninclude such factors as how quickly the user is scrolling. If the useris scrolling quickly, the system provides a more limited subset of theaddress book. As the user slows down the rate at which scrolling occurs,the system makes the stops between entries on the contact list closertogether.

Although the invention is described herein with reference to thepreferred embodiment, one skilled in the art will readily appreciatethat other applications may be substituted for those set forth hereinwithout departing from the spirit and scope of the present invention.Accordingly, the invention should only be limited by the Claims includedbelow.

1. An apparatus for delivery of network-based information and servicesvia a telephone handset, comprising: a broadband enabled telephonesystem in which SIP messages are sent to and from a SIP end point,comprising: at least one base station comprising: a first communicationsfacility; a broadband network connection for establishing andmaintaining broadband access to said network via said firstcommunications facility; and a second communications facility forinteracting with, and maintaining profile information for, a pluralityof handsets; and a plurality of handsets, each handset comprising: meansfor communicating with, and uniquely identifying itself to, said basestation via said second communications facility; client means forproviding an interface to a handset user by which said user operates ahandset to interact with said network via said base station and by whichsaid user builds a profile which defines what information and servicesare provided to a user through a particular handset: wherein said basestation acts as a proxy to said network for said handsets; wherein saidbase station stores at least a portion of said profile information; andwherein each handset is dynamically personalized for a plurality ofusers by user selection, via said client means, of a particular handsetprofile stored in said base station; and at least one server forcollecting, packaging, and delivering personalized content and serviceson demand to each of said telephone system handsets via said basestation in accordance with profile information contained on said basestation for said handsets; wherein information and services availablevia said network are delivered to a plurality of users of a plurality ofhandsets through said broadband enabled telephone system.
 2. Theapparatus of claim 1, said broadband enabled telephone system furthercomprising: a web service comprising a multi-layered system forproviding heterogeneous services to web service clients; wherein saidweb service comprises a portal for providing a single access point tosaid broadband enabled telephone system for a plurality of differentnetwork-based services
 3. The apparatus of claim 2, said network-basedservices comprising any of: email, voice mail, Internet Messaging,address book, and local search.
 4. The apparatus of claim 2, said webservice comprising: a web layer for handling all incoming user requestsfrom a client, marshalling and un-marshalling said requests, performingaccess control, and forwarding said requests to appropriate controllersfor resolution; a business/subscriber layer for consuming published datafrom the publishers and for personalizing said published data for saidusers; a publisher layer for interacting with service providers and forretrieving information from said service providers; and a databasepersistence layer for performing object relational mapping.
 5. Theapparatus of claim 4, further comprising: a toolkit for multicast,inter-process communication across LAN and/or WAN boundaries.
 6. Theapparatus of claim 4, said publishers comprising any of contentmanagers/gateways, email manager/gateways, and IM managers/gateways. 7.The apparatus of claim 4, said information comprising any of: email,weather, sports, address books, and instant message groups.
 8. Theapparatus of claim 4, further comprising: means for publishing saidinformation in well known repositories, which repositories comprise anyof a database and shared memory.
 9. The apparatus of claim 8, furthercomprising: means for notifying interested parties, once saidinformation is published, either by a publisher or an owner of saidpublished information.
 10. A method for delivery of network-basedinformation and services via a telephone handset, comprising the stepsof: providing a broadband enabled telephone system in which SIP messagesare sent to and from a SIP end point, comprising the steps of: providingat least one base station, comprising the steps of: providing a firstcommunications facility; providing a broadband network connection forestablishing and maintaining broadband access to said network via saidfirst communications facility; and providing a second communicationsfacility for interacting with, and maintaining profile information for,a plurality of handsets; and providing a plurality of handsets, the stepof providing each handset comprising the steps of: said handsetcommunicating with, and uniquely identifying itself to, said basestation via said second communications facility; providing a clientcomprising an interface to a handset user by which said user operates ahandset to interact with said network via said base station and by whichsaid user builds a profile which defines what information and servicesare provided to a user through a particular handset: wherein said basestation acts as a proxy to said network for said handsets; wherein saidbase station stores at least a portion of said profile information; andwherein each handset is dynamically personalized for a plurality ofusers by user selection, via said client, of a particular handsetprofile stored in said base station; and providing at least one serverfor collecting, packaging, and delivering personalized content andservices on demand to each of said telephone system handsets via saidbase station in accordance with profile information contained on saidbase station for said handsets; wherein information and servicesavailable via said network are delivered to a plurality of users of aplurality of handsets through said broadband enabled telephone system.11. The method of claim 10, said step of providing a broadband enabledtelephone system further comprising the step of: providing a web servicecomprising a multi-layered system for providing heterogeneous servicesto web service clients; wherein said web service comprises a portal forproviding a single access point to said broadband enabled telephonesystem for a plurality of different network-based services
 12. Themethod of claim 11, said network-based services comprising any of:email, voice mail, Internet Messaging, address book, and local search.13. The method of claim 11, said step of providing a web service furthercomprising the steps of: providing a web layer for handling all incominguser requests from a client, marshalling and un-marshalling saidrequests, performing access control, and forwarding said requests toappropriate controllers for resolution; providing a business/subscriberlayer for consuming published data from the publishers and forpersonalizing said published data for said users; providing a publisherlayer for interacting with service providers and for retrievinginformation from said service providers; and providing a databasepersistence layer for performing object relational mapping.
 14. Themethod of claim 13, further comprising the step of: providing a toolkitfor multicast, inter-process communication across LAN and/or WANboundaries.
 15. The method of claim 13, said publishers comprising anyof content managers/gateways, email manager/gateways, and IMmanagers/gateways.
 16. The method of claim 13, said informationcomprising any of: email, weather, sports, address books, and instantmessage groups.
 17. The method of claim 13, further comprising the stepof: publishing said information in well known repositories, whichrepositories comprise any of a database and shared memory.
 18. Themethod of claim 17, further comprising the step of: notifying interestedparties, once said information is published, either by a publisher or anowner of said published information.